Effective measures of software quality and development productivity (hereinafter “software productivity” unless otherwise indicated) can be important tools for predicting costs and evaluating the quality or benefit of completed projects. Existing methodologies typically are variations on one or both of two techniques: (1) lines of code (hereinafter “LOC”) measures; and (2) function point analysis.
LOC measures simply count the number of lines of text of a program's source code. Cost and benefit are determined by simply calculating the dollar cost per line of code. LOC measures are simple to understand, easy to compare, and easy to collect. However, while effort may be highly correlated with LOC measures, the amount of functionality of the software is not necessarily heavily correlated to LOC. Moreover, effort is less correlated with LOC measures since the advent of so called “high-level” programming languages that may require extensive pre-programming activities such as drafting requirements and design diagrams. In that case, LOC could drastically underestimate the effort required to code software. Thus, LOC measures may provide an adequate measure of an individual programmer's raw output, but fail to capture the functional quality of that output.
Function point analysis measures the amount of functionality the software provides a user. For example, function point analysis awards more points to a program that provides a user the capability to perform ten essential business tasks than to a program that provides a user the capability to perform only four similarly essential business tasks. Different tasks may be scored differently based on metrics such as type and complexity. Function point analysis by itself does not necessarily provide a measure of how much effort went into developing the software. Further, function point analysis may include some significant element of subjectivity.
Software reuse is widely accepted as a beneficial technique for managing the cost of developing software. In particular, the reuse of quality software to save resources is a widely accepted goal. The simple LOC measures described above may actually disincent reuse. Reuse incurs the cost of learning the use of the component, which may be offset by the functionality provided by the reusable component. However, using LOC measures of “work size” or output simply accounts for the cost of learning without factoring in the benefit of reuse into the lines of code measure, which could result in an inaccurate lower productivity metric for an otherwise effective example of reuse. Thus, reuse metrics may be used to improve both LOC measures and the function point analysis. Measuring reuse may be cumbersome or even impossible. The traditional way of calculating reuse involves manual effort, where the number of lines of code of both the created code and the reused code are counted (using either manual counts or through a line counting tool) and then are used to calculate the reuse percentage. This is difficult if the source code of the reused libraries are unavailable, which is typically the case for reused software. Even when source code is available, it is difficult to manually identify the re-used parts of code from the library, so manual measures of reuse will typically over-estimate the reuse measurement when the entire library is counted.
Thus, there is a need for a convenient and automated technique for measuring code reuse. With such a technique, there is still a need for useful reuse metrics that utilize such a technique.